This is a monthly segment in which Versant Object Technology touches upon some aspect of object databases. This month's tip focuses on object retrieval philosophy.

USING GROUP READS

From reading the VERSANT data sheets, one quickly discovers that the default level of object retrieval within a VERSANT ODBMS application is at the object level. Suppose all you request is a specific object to be retrieved into your front-end cache for a client application in a client/server environment. You certainly would only want to retrieve that object and not all the other objects which may be on the same page as the object of interest. If you were to perform retrieval at the page level, this would not only waste bandwidth as useless bytes of data would have to travel over a network (or bus), but also have severe repercussions upon concurrency as locking would have to be performed at the page level, not the object level.

Now the question is what happens if you want to retrieve a group of objects, not just just one? Clearly, retrieving one object at a time would be slower than retrieving all of them at once. To do this, a concept called group reads can be utilized.

For example, suppose you were to perform a query with a select statement. Versant performs queries on the back end and returns references for all objects which match the criteria of the query. When a particular reference within this list of objects is dereferenced, it is brought into the front-end cache and instantiated. Rather than do this one object at a time, you can call a method called greadobjs() (or groupRead in Smalltalk) which will read all the objects of interest into the front-end cache and instantiate them within it. Again, only the objects of interest are retreived and placed within the cache, not the pages which may contain these objects and other superfluous objects, thus maximizing total useful throughput. Moreover, you can use the concept of group reads on VERSANT collection classes such as arrays or lists and on Smalltalk collection classes too. Finally, if the needs of your application call for locality of reference for objects of the same class, you can call the cluster() method (or clusterClasses in Smalltalk) to cluster objects of the same class within the disk. This would make the group read method even faster as disk seek time would decrease on the back end.

WHAT ABOUT REFERENCES

Now, suppose you have objects which point to other objects and so forth. Given a list of objects from a query, you would like to retrieve all objects which are "pointed to" by the original objects that match the query. Versant provides the ability to not only perform this task through a method called getclosure() (or getClosureFromDB in Smalltalk), but also the ability to perform transitive closures to retrieve references to all possible objects that can be "navigated to" starting from a group of objects. A group read can then be performed to retrieve all these objects at once and instantiate them within the front-end cache. The select, closure and group read functionality can all be combined in an option on VERSANT's select method to optimize even further.

The ability to retrieve objects at the object level not only provides lots of flexibility as in the cases of performing a multi-level select or supporting concurrent users, but also increases the performance of your application as only the requested objects are retrieved. It is for this reason that the philosophy of utilizing object-level retrieval is not only a powerful maxim, but also a necessity in maximizing performance and concurrency.

by Nimish Doshi

[ What's New | Products | Partners | Tech Support | About Us | Employment | Contact Us | Search | Home ]
[ C++ Solutions | SmallTalk Solutions | Internet Solutions ]